1. Field of the Invention
The invention relates to network management, specifically to a method and a system for configuration discovery.
2. Description of the Related Art
The purpose of network management is to manage network performance, discover and solve network problems, and plan for network growth. As defined in V. M. Swisher et al., Mastering Network Management, Numidia Press, Fremont, 1997, network management functions can be divided into fault, configuration, performance, security, and accounting management.
Fault management comprises prophylaxis, detection, and restoration of faulty physical devices of the network. Physical devices of the network are, for example, cables, connectors, switches, bridges, hubs, routers, etc. Configuration management includes planning, extending, and changing the network configuration as well as obtaining information about the current hardware topology of the network. Since the present invention is specifically related to configuration management, configuration management is explained in more detail below. Performance management includes measuring and improving the performance of the network. The purpose of security management is to manage the access to the network itself or to specific resources on the network. Accounting management is, for example, used to attribute usage of at least parts of the network to specific entities within a company's network.
In order to realize network management, a mechanism for management communication (i.e., a network management system) has to be implemented. The network management system comprises a manager and agents. The manager is a piece of software residing on a Network Management Station (NMS). An NMS, sometimes called a console, executes management applications that monitor and control managed devices. Physically, an NMS is usually an engineering workstation with a fast CPU, megapixel color display, substantial memory, and abundant disk space. Managed devices are hardware devices of the network such as computers, routers, and terminal servers that are connected to the network. The manager requests information from the managed devices regarding operational parameters, configuration settings, and other specific information based on the managed device type. In order to respond to a query from the NMS, appropriate software, called an agent, resides on each managed device. Along with the agent, each managed device comprises a database which is operatively coupled with the agent. The database is comprised of information needed for the manager to query and is composed of a list of managed objects. Managed objects are the actual units of management information in the database.
When the manager makes a specific request, the agent of the managed device looks up the management information stored on the database and passes the requested information back to the manager. The contents of the database are specific to the type of managed device being queried.
In order to convey management information between the managed device and the NMS, a particular network management protocol is used. Well known management protocols are, for example, the Simple Network Management Protocol (SNMP) and the Common Management Information Protocol (CMIP). SNMP was developed by the Internet community and was designed to run on Internet Protocol (IP). CMIP was designed by the International Telecommunication Union (ITU). CMIP is an Open System Interconnection (OSI)-style management protocol. If a SNMP-protocol is used, the agent and the manager are often referred to as an SNMP-agent and an SNMP-manager, respectively. The database operatively coupled to the SNMP-agent is also called a management information base (MIB).
Communication between the NMS and the managed devices, i.e., between the manager and the agents, is initiated by the manager. The agent can initiate a communication with the manager only if a catastrophic or near-catastrophic event occurs. This type of communication is called a trap. For example, SNMP defines seven types of traps: Cold boot, warm boot, link down, link up, authentication failure, Exterior Gateway Protocol (EGP) neighbor loss, and enterprise-specific.
A special concern of the invention is configuration management, more specifically configuration discovery. The network's hardware configuration is a map of where the hardware devices of the network are placed in relation to other hardware devices. Hardware devices comprise hubs, routers, computers, bridges, etc. In order to manage the configuration of the network and especially to discover the topology of the network, the manager comprises a configuration discovery application.
The configuration discovery application is a piece of software residing on the NMS. When initiating the discovery application from the NMS, a request is sent from the NMS to the managed devices. Each agent residing on the managed devices receives the request, looks up the requested management information stored in its associated database, and sends a management protocol back to the manager. Each management protocol comprises information about the type of each discovered managed device, so that each discovered managed device and therefore the network topology can be displayed as, for example, an icon specifically assigned to the managed device type on a Graphical User Interface (GUI) of the NMS. The GUI can be, for example, the display of the NMS. The specific managed device type may be a bridge, a switch, a router, or a computer, among others. Therefore, the graphical display of the topology of the discovered network comprises one or more generic icons representing routers, bridges, computers, etc. depending on the discovered managed devices of the network. Sometimes, the database of an agent residing on a computer comprises additional information about the type of operating system of the computer. Then, the displayed icon comprises also information about the operating system of the discovered computer.
Sometimes, however, a representation of a discovered managed device needs to show more detailed information. Such detailed information can be, for instance, a specific application run on that managed device. For example, if a discovered computer controls a machine or an apparatus, perhaps a medical apparatus, then the displayed representation of that computer must comprise information about the type of machine or apparatus controlled by that discovered computer. Then, according to the state of the art, the icon of the represented computer has to be manually replaced by an icon representing the machine or the apparatus controlled by the computer. The replaced icon comprises information about the specific application to be visualized.
FIG. 1 depicts an example of a network comprised of several computers 1 to 10. One of the computers is a NMS 1. On the NMS 1 resides a SNMP-manager which comprises an appropriate configuration discovery application. On each of the remaining computers 2 to 10 resides a SNMP-agent with a MIB operatively coupled to the respective SNMP-agent according to the state of the art. Consequently, the computers 2 to 10 are managed devices, which can be discovered by the SNMP-manager residing on the NMS 1. Furthermore, computer 3 controls a magnetic resonance apparatus 3a, computer 4 controls an X-ray apparatus, and computer 7 controls a computed tomography apparatus 7a. 
The structure of a SNMP-agent 20 and its MIB 21 according to the state of the art is schematically depicted in FIG. 2. Each MIB 21 stores, among other things, information about the operating system of each associated computer 2 to 10. Besides information about the operating system, the MIB 21, however, does not store information about specific applications run on its associated computer 2 to 10. The information about the operating system is coded as a parameter specific to the operating system. In this case, computers 2, 3, 6, 9, and 10 are run by Microsoft Windows NT operating systems, computers 4, 7, and 8 are run by Solaris/SunOS (SUN Unix) operating systems, and computer 5 is run by a Hewlett-Packard Unix operating system. Systems running alternative operating systems could also be included.
When a query to discover the network is initiated by the NMS 1, each SNMP-agent 20 receives this request (step A of the flow chart shown in FIG. 3). Then, each SNMP-agent 20 retrieves the requested information, i.e., the parameter corresponding to the requested information, from its MIB 21 (step B of the flow chart shown in FIG. 3) and sends a SNMP-protocol comprising the retrieved parameter to the SNMP-manager (step C of the flow chart shown in FIG. 3).
Upon receiving the SNMP-protocols, the SNMP-manager displays a representation of the network on a screen 1 a of the NMS 1 (step D of the flow chart shown in FIG. 3). The representation of the discovered network, which is shown in FIG. 4, comprises icons 41 to 49, which represent computers 2 to 10. The icons 41 to 49 are stored on a database 1b, which is operatively coupled with the SNMP-manager and resides on the NMS 1. Additionally, each icon 41 to 49 comprises information about the operating system running on the respective computer 2 to 10. Specifically, icons 41, 42, 45, 48, and 49 represent computers which are run by Microsoft Windows NT operating systems, icons 43, 46, and 47 represent computers run by solaris/sunos (SUN Unix) operating systems, and icon 44 represents a computer run by a Hewlett-Packard Unix operating system. Since each SNMP-protocol comprises information associated with the operating system of its respective computer 2 to 10, the SNMP-manager can retrieve the appropriate icon 41 to 49 from database 1b. Nevertheless, according to the state of the art, the SNMP-manager cannot receive information regarding a specific application run on computers 2 to 10. Specifically, the SNMP-manager cannot receive information about the type of apparatuses controlled by computers 3, 4, and 7.